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1.  Introduction 

Building  robust,  secure  distributed  systems  in  the  pres¬ 
ence  of  transient  faults,  node  failures,  and  changes  in  net¬ 
work  topology  poses  a  multitude  of  challenges.  Most  sys¬ 
tems  being  built  today  are  the  integration  of  highly  dis¬ 
parate  hardware  and  software  components  that  interact  via 
a  hardware  bus  or  middleware  infrastructure.  During  the 
design  of  a  component,  non-functional  requirements  such 
as  fault-tolerance  may  complicate  the  design  and  are  better 
addressed  during  hardware/software  integration  by  altering 
the  run-time  behavior  of  components.  Architectural  pat¬ 
terns,  analogous  to  design  patterns,  are  a  means  to  develop 
such  mechanisms  rapidly  by  reusing  existing  solutions. 

To  meet  current  engineering  challenges  such  as  perva¬ 
sive  and  ubiquitous  computing  [8],  one  must  adopt  model- 
driven  approaches  to  build  distributed  applications.  We  pro¬ 
pose  the  synchronous  paradigm  for  component  integration 
and  coordination:  developers  use  an  abstraction  that  re¬ 
spects  the  synchrony  hypothesis,  i.e.,  each  external  event 
is  processed  by  the  system  completely  before  the  arrival 
of  the  next  event.  Based  on  the  synchronous  model,  the 
Secure  Operations  Language  (SOL)  [2]  is  designed  as  a 
verifiable  language  for  the  integration  of  high  assurance 
systems.  Programs  in  SOL  are  amenable  to  fully  auto¬ 
mated  static  analysis — such  as  automatic  theorem  prov¬ 
ing  [5],  or  model  checking  [4] —  to  ensure  compliance  with 
application- specific  requirements. 

A  module  is  the  unit  of  specification  in  SOL.  An  agent 
is  a  module  instance.  Assumptions  for  correct  agent  oper¬ 
ation  may  be  specified:  execution  of  the  agent  aborts  when 
any  assumption  is  violated.  Fault- tolerant  patterns,  similar 
to  the  one  we  discuss  in  the  sequel,  may  be  used  to  deal  with 
such  exceptions  in  mission  critical  systems.  Guarantees  are 
the  required  safety  properties  of  the  agent.  A  SOL  mod¬ 
ule  specifies  the  required  relation  between  input  monitored 
variables ,  and  output  controlled  variables.  Each  dependent 
variable  (controlled  as  well  as  additional  internal  variables) 
is  defined  as  a  function  of  other  module  variables.  SOL,  like 
SCR  [7],  is  an  event-driven  language,  and  borrows  many 
concepts  from  that  language  as  well  as  from  LUSTRE  [6]. 
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Fault-Tolerant  Component 


Figure  1.  Hot  Standby  Pattern  Architecture. 


SOL  agents  run  on  a  distributed  infrastructure  SINS  [3]. 
A  SINS  application  comprises  a  set  of  software  agents  that 
use  services  provided  by  SINS  virtual  machines  on  dis¬ 
parate  hosts  over  a  network.  SINS  provides  mechanisms 
for  the  creation,  deployment,  and  migration  of  agents,  in  ad¬ 
dition  to  protocols  for  inter-agent  communication  and  syn¬ 
chronization.  SINS  uses  the  SPREAD  toolkit  [1]  to  provide 
a  high  performance  virtual  synchrony  messaging  service. 

2.  Architectural  Patterns 

To  meet  fault  tolerance,  security,  and  real-time  require¬ 
ments  of  applications,  we  have  extended  SOL.  Formal  ar¬ 
chitectural  patterns  can  be  instantiated  and  then  automat¬ 
ically  compiled  to  a  group  of  SINS  agents  running  in  a 
distributed  environment.  We  describe  the  language  exten¬ 
sions  in  the  context  of  an  architectural  pattern  denoted  “Hot 
Standby,”  which  provides  a  measure  of  fault- tolerant  behav¬ 
ior  via  replication. 

In  the  Hot  Standby  pattern  a  function  performed  by 
an  agent  at  a  primary  site  is  replicated  at  a  secondary 
“Standby”  site.  In  this  pattern,  the  failure  of  the  primary 
site  simply  means  computation  results  are  retrieved  from 
the  secondary  site  rather  than  the  failed  primary  site. 

The  Hot  Standby  pattern  of  Figure  1  is  a  generalization 
of  the  pattern  given  in  [12]  and  is  specified  in  an  extension 
of  SOL.  In  the  extended  language,  we  assume  any  module 
A  has  available  attributes  that  can  be  accessed  when  writ¬ 
ing  architectural  patterns.  These  include  Boolean  variables 
X.f  ail  indicating  failure  status  of  the  sub-modules  X  of  A, 
and  generic  descriptions  of  groups  of  variables  computed  by 
each  sub-module  (such  as  X.Mon  for  the  tuple  of  monitored 
variables  comprising  X’s  input). 


Additionally  we  employ  temporal  observer  modules 
(such  as  NEVER(B),  meaning  that  B  has  never  been  true)  in 
describing  the  assumptions  and  guarantees  of  extended  SOL 
modules.  This  notion  of  temporal  observers  was  pioneered 
in  the  LUSTRE  language  [6]. 

We  emphasize  that  sub-modules  of  architectural  patterns 
need  not  be  compilations  of  modules  written  in  SOL.  The 
sub-modules  may  be  any  COTS  hardware/software  compo¬ 
nents  that  satisfy  the  appropriate  assumptions  and  provide 
the  given  guarantees  (as  invariants). 

3.  Proof  of  Correctness 

We  have  used  the  theorem  prover  PVS  [1 1]  for  formulat¬ 
ing  and  proving  the  major  invariant  of  Hot  Standby: 

(*)  NEVER(primary.f  ail)  or  NEVER(secondary.f  ail) 
=4>  “Function  computed  correctly” 

We  have  shown  this  result  for  a  general  vector-valued  se¬ 
quential  function  over  the  history  of  the  system  (not  simply 
a  combinatorial  function).  PVS  is  convenient  for  the  proofs 
of  invariants  of  architectural  patterns  since  it  supports  defi¬ 
nition  of  uninterpreted  functions  in  a  general  setting. 

Invariance  of  q  for  any  instance  of  an  architectural  pat¬ 
tern  A  follows  from  invariance  of  q  for  that  instance  of  A  in 
which  the  sub-modules  are  the  most  general  ones  satisfying 
the  assumptions  and  guarantees  imposed  by  A  (this  is  a  vari¬ 
ant  of  the  compositional  proof  rule  given  in  [9]).  Proof  of 
(*)  for  the  most  general  instance  was  done  by  the  computa¬ 
tional  induction  method  of  [10]:  (1)  the  property  must  hold 
initially  and  (2)  assuming  that  it  holds  in  any  state  implies 
it  must  hold  in  the  next  state;  previously  proved  or  assumed 
invariants  may  be  used  as  auxiliary  lemmas. 

4.  Related  Work 

Several  languages  for  describing  architectural  patterns 
at  various  levels  of  abstraction  exist,  ranging  from  UML 
to  languages  for  describing  system  architectures.  However 
none  of  these  languages  has  a  well-defined  formal  opera¬ 
tional  or  denotational  semantics,  which  is  necessary  for  the 
development  of  architectural  specifications  with  verifiable 
properties.  The  use  of  architectural  patterns  for  dependabil¬ 
ity  was  introduced  by  Yau,  et  al.  in  [12]. 

5.  Conclusions  and  Future  Work 

Our  initial  study  of  formal  verification  of  architectural 
patterns  has  shown  it  is  straightforward  to  prove  a  safety 
property  associated  with  a  generic  module  Hot  Standby.  We 
have  outlined  the  general  proof  methodology,  and  are  in  the 
process  of  applying  this  methodology  to  examples  that  truly 
require  this  level  of  formal  support.  We  envision  developing 
and  proving  complex,  parameterized,  architectural  patterns 
with  careful  attention  to  requisite  assumptions.  Our  vision 


is  that  the  hardware  or  software  designer  will  use  automatic 
verification  tools  such  as  model  checkers  to  prove  that  the 
components  of  an  architectural  pattern  instance  satisfy  the 
assumptions  and  guarantees  of  that  pattern.  In  future  work 
we  plan  to  refine  the  computational  induction  proof  method¬ 
ology  and  to  extend  SOL  with  a  polymorphic  type  system 
in  support  of  more  general  architectural  patterns. 

The  overall  goal  of  the  NRL  dependable  middleware 
project  is  to  develop  infrastructure  that  supports  the  devel¬ 
opment  of  secure  encapsulation  mechanisms  for  untrusted 
hardware  and  software  COTS  components.  With  such  en¬ 
capsulation  mechanisms  it  should  be  feasible  to  protect 
mission-critical  distributed  applications  and  to  design  sys¬ 
tems  that  provide  continued  service  in  the  presence  of  faults 
or  malicious  attacks. 
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